From 64f53be44cd6359a001acd2fae7ea3bd20b16c3b Mon Sep 17 00:00:00 2001 From: Eddy Nakamura Date: Mon, 31 Jan 2022 18:12:18 -0800 Subject: [PATCH] Updating SARIF-SDK submodules --- .../Expected/BinSkim.win-x64.ni.dll.sarif | 132 +++++++++--------- .../Expected/BinSkim.win-x86.ni.dll.sarif | 132 +++++++++--------- .../Expected/Binskim.linux-x64.dll.sarif | 128 ++++++++--------- .../Expected/Binskim.win-x64.RTR.dll.sarif | 132 +++++++++--------- .../Expected/Binskim.win-x64.dll.sarif | 128 ++++++++--------- .../Expected/Binskim.win-x86.RTR.dll.sarif | 132 +++++++++--------- .../Expected/Binskim.win-x86.dll.sarif | 128 ++++++++--------- ...rupted_Native_x86_VS2013_Default.exe.sarif | 12 -- ...ore_RTR_linux-x64_VS2019_Default.dll.sarif | 132 +++++++++--------- ...tCore_RTR_win-x64_VS2019_Default.dll.sarif | 132 +++++++++--------- ...tCore_RTR_win-x86_VS2019_Default.dll.sarif | 132 +++++++++--------- ...NetCore_linux-x64_VS2019_Default.dll.sarif | 132 +++++++++--------- ...otNetCore_win-x64_VS2019_Default.dll.sarif | 132 +++++++++--------- ...otNetCore_win-x64_VS2019_Default.exe.sarif | 132 +++++++++--------- ...otNetCore_win-x86_VS2019_Default.dll.sarif | 132 +++++++++--------- ...InteropAssemblyForAtlTestLibrary.dll.sarif | 128 ++++++++--------- .../Expected/ManagedResourcesOnly.dll.sarif | 128 ++++++++--------- ...aged_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif | 132 +++++++++--------- ...anaged_AnyCPU_VS2017_Prefer32Bit.exe.sarif | 132 +++++++++--------- .../Managed_x64_VS2015_FSharp.exe.sarif | 132 +++++++++--------- ...VS2019_CSharp_DebugType_Embedded.dll.sarif | 132 +++++++++--------- ...x64_VS2019_CSharp_DebugType_Full.dll.sarif | 132 +++++++++--------- ...x64_VS2019_CSharp_DebugType_None.dll.sarif | 128 ++++++++--------- ..._VS2019_CSharp_DebugType_PdbOnly.dll.sarif | 132 +++++++++--------- ...VS2019_CSharp_DebugType_Portable.dll.sarif | 132 +++++++++--------- ...x64_VS2019_VB_DebugType_Embedded.dll.sarif | 132 +++++++++--------- ...ged_x64_VS2019_VB_DebugType_Full.dll.sarif | 132 +++++++++--------- ...ged_x64_VS2019_VB_DebugType_None.dll.sarif | 128 ++++++++--------- ..._x64_VS2019_VB_DebugType_PdbOnly.dll.sarif | 132 +++++++++--------- ...x64_VS2019_VB_DebugType_Portable.dll.sarif | 132 +++++++++--------- .../Expected/Managed_x86_VS2013_Wpf.exe.sarif | 132 +++++++++--------- .../Managed_x86_VS2015_FSharp.dll.sarif | 132 +++++++++--------- .../MixedMode_x64_VS2013_Default.dll.sarif | 132 +++++++++--------- .../MixedMode_x64_VS2013_NoPdb.exe.sarif | 92 ++++++------ .../MixedMode_x64_VS2015_Default.exe.sarif | 132 +++++++++--------- ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 132 +++++++++--------- ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 132 +++++++++--------- ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 132 +++++++++--------- ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 92 ++++++------ .../MixedMode_x86_VS2013_Default.exe.sarif | 132 +++++++++--------- .../MixedMode_x86_VS2013_MissingPdb.dll.sarif | 92 ++++++------ .../MixedMode_x86_VS2015_Default.exe.sarif | 132 +++++++++--------- ...ve_ARM_VS2015_CvtresResourceOnly.dll.sarif | 128 ++++++++--------- .../Native_x64_VS2013_Default.dll.sarif | 132 +++++++++--------- ...ve_x64_VS2015_CvtresResourceOnly.dll.sarif | 128 ++++++++--------- .../Native_x64_VS2015_Default.dll.sarif | 132 +++++++++--------- ...ve_x64_VS2019_Atl_NoPdbGenerated.dll.sarif | 92 ++++++------ ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 132 +++++++++--------- ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 132 +++++++++--------- ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 132 +++++++++--------- ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 92 ++++++------ .../Native_x64_VS2019_SDL_Enabled.exe.sarif | 132 +++++++++--------- ...tive_x64_VSCode_Rust_DebugInfo_0.exe.sarif | 132 +++++++++--------- ...tive_x64_VSCode_Rust_DebugInfo_1.exe.sarif | 132 +++++++++--------- ...tive_x64_VSCode_Rust_DebugInfo_2.exe.sarif | 132 +++++++++--------- .../Native_x86_VS2012_SDL_Enabled.exe.sarif | 132 +++++++++--------- .../Native_x86_VS2013_Default.exe.sarif | 132 +++++++++--------- .../Native_x86_VS2013_PdbMissing.exe.sarif | 92 ++++++------ .../Native_x86_VS2013_ResourceOnly.dll.sarif | 132 +++++++++--------- ...Native_x86_VS2015_AtlProxyStubPS.dll.sarif | 132 +++++++++--------- ...ve_x86_VS2015_CvtresResourceOnly.dll.sarif | 128 ++++++++--------- .../Native_x86_VS2015_Default.exe.sarif | 132 +++++++++--------- .../Native_x86_VS2015_Default_Debug.dll.sarif | 132 +++++++++--------- ...ve_x86_VS2017_15.5.4_PdbStripped.dll.sarif | 92 ++++++------ .../Native_x86_VS2019_SDL_Enabled.exe.sarif | 132 +++++++++--------- .../Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif | 132 +++++++++--------- .../Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif | 104 +++++++------- .../Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif | 92 ++++++------ .../Expected/Uwp_ARM_VS2017_VB.dll.sarif | 132 +++++++++--------- ...wp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif | 132 +++++++++--------- .../Uwp_x64_VS2015_DefaultBlankApp.dll.sarif | 104 +++++++------- .../Uwp_x64_VS2015_DefaultBlankApp.exe.sarif | 92 ++++++------ .../Expected/Uwp_x64_VS2017_Cpp.dll.sarif | 132 +++++++++--------- .../Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif | 132 +++++++++--------- .../Uwp_x86_VS2015_DefaultBlankApp.dll.sarif | 104 +++++++------- .../Uwp_x86_VS2015_DefaultBlankApp.exe.sarif | 92 ++++++------ .../Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif | 132 +++++++++--------- .../Wix_3.11.1_VS2017_Bootstrapper.exe.sarif | 132 +++++++++--------- .../Expected/clang.default_compilation.sarif | 128 ++++++++--------- .../Expected/clang.elf.objectivec.dwarf.sarif | 132 +++++++++--------- .../Expected/clang.execstack.sarif | 128 ++++++++--------- .../Expected/clang.execstack.so.sarif | 128 ++++++++--------- .../Expected/clang.immediate_binding.sarif | 128 ++++++++--------- .../Expected/clang.no_immediate_binding.sarif | 128 ++++++++--------- .../Expected/clang.no_stack_protector.sarif | 128 ++++++++--------- .../Expected/clang.noexecstack.sarif | 128 ++++++++--------- .../Expected/clang.noexecstack.so.sarif | 128 ++++++++--------- .../Expected/clang.non_pie_executable.sarif | 128 ++++++++--------- .../Expected/clang.object_file.o.sarif | 128 ++++++++--------- .../Expected/clang.pie_executable.sarif | 128 ++++++++--------- .../Expected/clang.relocationsro.sarif | 128 ++++++++--------- .../Expected/clang.relocationsrw.sarif | 128 ++++++++--------- .../Expected/clang.shared_library.so.sarif | 128 ++++++++--------- .../Expected/clang.stack_protector.a.sarif | 12 -- .../Expected/clang.stack_protector.sarif | 128 ++++++++--------- .../Expected/clang.stack_protector.so.sarif | 128 ++++++++--------- .../clangcl.pe.cpp.codeview.exe.sarif | 132 +++++++++--------- .../Expected/gcc.default_compilation.sarif | 128 ++++++++--------- ...rongsspbuffersize8+fnostackprotector.sarif | 132 +++++++++--------- .../Expected/gcc.execstack.sarif | 128 ++++++++--------- .../Expected/gcc.execstack.so.sarif | 128 ++++++++--------- .../Expected/gcc.fortified.sarif | 128 ++++++++--------- .../Expected/gcc.gsplitdwarf.5.dwo.sarif | 132 +++++++++--------- .../Expected/gcc.gsplitdwarf.5.sarif | 132 +++++++++--------- ...oworld.4.o.no-stack-clash-protection.sarif | 132 +++++++++--------- ...oworld.5.o.no-stack-clash-protection.sarif | 132 +++++++++--------- .../gcc.helloworld.execstack.5.o.sarif | 132 +++++++++--------- .../Expected/gcc.helloworld.nodwarf.sarif | 128 ++++++++--------- .../gcc.helloworld.noexecstack.5.o.sarif | 132 +++++++++--------- .../Expected/gcc.immediate_binding.sarif | 128 ++++++++--------- .../gcc.no_fortification_required.sarif | 128 ++++++++--------- .../Expected/gcc.no_immediate_binding.sarif | 128 ++++++++--------- .../Expected/gcc.no_stack_protector.sarif | 128 ++++++++--------- .../Expected/gcc.noexecstack.sarif | 128 ++++++++--------- .../Expected/gcc.noexecstack.so.sarif | 128 ++++++++--------- .../Expected/gcc.non_pie_executable.sarif | 128 ++++++++--------- ...objcopy.stripall.addgnudebuglink.dbg.sarif | 132 +++++++++--------- ...gcc.objcopy.stripall.addgnudebuglink.sarif | 128 ++++++++--------- .../Expected/gcc.object_file.o.sarif | 128 ++++++++--------- .../gcc.pe.objectivec.dwarf.exe.sarif | 92 ++++++------ .../Expected/gcc.pie_executable.sarif | 128 ++++++++--------- .../Expected/gcc.relocationsro.sarif | 128 ++++++++--------- .../Expected/gcc.relocationsrw.sarif | 128 ++++++++--------- .../Expected/gcc.requiredsymbol.4.o.sarif | 132 +++++++++--------- .../Expected/gcc.requiredsymbol.5.o.sarif | 132 +++++++++--------- .../Expected/gcc.shared_library.so.sarif | 128 ++++++++--------- .../Expected/gcc.stack_protector.a.sarif | 12 -- .../Expected/gcc.stack_protector.sarif | 128 ++++++++--------- .../Expected/gcc.stack_protector.so.sarif | 128 ++++++++--------- .../Expected/gcc.unfortified.sarif | 128 ++++++++--------- src/sarif-sdk | 2 +- 131 files changed, 8027 insertions(+), 8063 deletions(-) diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif index 6c43d65db..2d20ebc71 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -923,17 +923,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1063,17 +1063,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1091,17 +1091,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1125,14 +1125,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1147,14 +1147,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1169,14 +1169,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1194,14 +1194,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1219,14 +1219,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1241,14 +1241,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1263,14 +1263,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1285,14 +1285,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1307,14 +1307,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1329,14 +1329,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1351,14 +1351,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1379,14 +1379,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1401,14 +1401,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1423,14 +1423,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1445,17 +1445,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1473,17 +1473,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1504,17 +1504,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1529,17 +1529,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1563,17 +1563,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1588,17 +1588,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1616,17 +1616,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif index 2ff88948d..a8c0d8a14 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -862,14 +862,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -887,17 +887,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -918,17 +918,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -946,17 +946,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1030,17 +1030,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1095,14 +1095,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1117,14 +1117,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1139,14 +1139,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1164,14 +1164,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1189,14 +1189,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1211,14 +1211,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1233,14 +1233,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1277,14 +1277,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1299,14 +1299,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1321,14 +1321,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1418,17 +1418,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1449,17 +1449,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1474,17 +1474,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif index 96bd3efce..f128259b3 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif @@ -772,10 +772,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -790,17 +790,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -815,17 +815,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -843,17 +843,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -874,17 +874,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -902,17 +902,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -955,17 +955,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -989,17 +989,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1020,17 +1020,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1045,17 +1045,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1076,17 +1076,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1163,14 +1163,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1185,14 +1185,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1207,14 +1207,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1232,14 +1232,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1257,14 +1257,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1279,14 +1279,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1301,14 +1301,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1323,14 +1323,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1417,14 +1417,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1439,14 +1439,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1461,14 +1461,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1486,17 +1486,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1517,17 +1517,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1542,17 +1542,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1570,17 +1570,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif index 62462cbb0..86572d8ea 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -923,17 +923,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1063,17 +1063,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1091,17 +1091,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1125,14 +1125,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1147,14 +1147,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1169,14 +1169,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1194,14 +1194,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1219,14 +1219,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1241,14 +1241,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1263,14 +1263,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1285,14 +1285,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1307,14 +1307,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1329,14 +1329,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1351,14 +1351,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1379,14 +1379,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1401,14 +1401,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1423,14 +1423,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1445,17 +1445,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1473,17 +1473,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1504,17 +1504,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1529,17 +1529,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1563,17 +1563,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1588,17 +1588,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1616,17 +1616,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif index 57417ded1..4e3d56b80 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif @@ -772,10 +772,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -790,17 +790,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -815,17 +815,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -843,17 +843,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -874,17 +874,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -902,17 +902,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -955,17 +955,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -989,17 +989,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1020,17 +1020,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1045,17 +1045,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1076,17 +1076,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1163,14 +1163,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1185,14 +1185,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1207,14 +1207,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1232,14 +1232,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1257,14 +1257,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1279,14 +1279,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1301,14 +1301,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1323,14 +1323,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1417,14 +1417,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1439,14 +1439,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1461,14 +1461,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1486,17 +1486,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1517,17 +1517,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1542,17 +1542,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1570,17 +1570,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif index be4a16ba1..e31834255 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -862,14 +862,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -887,17 +887,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -918,17 +918,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -946,17 +946,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1030,17 +1030,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1095,14 +1095,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1117,14 +1117,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1139,14 +1139,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1164,14 +1164,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1189,14 +1189,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1211,14 +1211,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1233,14 +1233,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1277,14 +1277,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1299,14 +1299,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1321,14 +1321,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1418,17 +1418,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1449,17 +1449,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1474,17 +1474,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif index 8efdebd1d..cffb8cf48 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -839,17 +839,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -870,17 +870,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -898,17 +898,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1016,17 +1016,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1041,17 +1041,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1106,14 +1106,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1128,14 +1128,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1150,14 +1150,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1175,14 +1175,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1222,14 +1222,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1244,14 +1244,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1266,14 +1266,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1288,14 +1288,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1310,14 +1310,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1360,14 +1360,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1382,14 +1382,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1404,14 +1404,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1460,17 +1460,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1566,17 +1566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1597,7 +1597,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif index 1ed0528af..a2bd388ee 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif @@ -38,18 +38,6 @@ "executionSuccessful": false } ], - "artifacts": [ - { - "location": { - "uri": "file:///Z:/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Corrupted_Native_x86_VS2013_Default.exe" - }, - "hashes": { - "md5": "992F5D2554195F9F19B9480A0E11AC78", - "sha-1": "A88412258FFEAC619F3FD960AD9A48AC2F29CBAE", - "sha-256": "9F92EDE722DC8740BFDF02CD199090B249BFBBF268DE3CD541FE9400A5652166" - } - } - ], "columnKind": "utf16CodeUnits" } ] diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif index 55823c135..502380907 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif @@ -795,10 +795,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -838,17 +838,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -897,17 +897,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -925,17 +925,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -950,17 +950,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -978,17 +978,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1012,17 +1012,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1043,17 +1043,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1152,17 +1152,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1186,14 +1186,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1208,14 +1208,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1280,14 +1280,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1302,14 +1302,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1440,14 +1440,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1462,14 +1462,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1593,17 +1593,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1621,17 +1621,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1652,7 +1652,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif index f946b8c9a..66b54759d 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif @@ -795,10 +795,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -838,17 +838,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -897,17 +897,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -925,17 +925,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -950,17 +950,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -978,17 +978,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1012,17 +1012,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1043,17 +1043,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1152,17 +1152,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1186,14 +1186,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1208,14 +1208,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1280,14 +1280,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1302,14 +1302,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1440,14 +1440,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1462,14 +1462,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1593,17 +1593,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1621,17 +1621,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1652,7 +1652,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif index 5eeb6b548..91787bf16 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif index c7076a5bf..76947c738 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif @@ -795,10 +795,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -838,17 +838,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -897,17 +897,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -925,17 +925,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -950,17 +950,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -978,17 +978,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1012,17 +1012,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1043,17 +1043,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1152,17 +1152,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1186,14 +1186,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1208,14 +1208,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1280,14 +1280,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1302,14 +1302,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1440,14 +1440,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1462,14 +1462,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1593,17 +1593,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1621,17 +1621,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1652,7 +1652,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif index cdf60b472..c47af0014 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif @@ -795,10 +795,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -838,17 +838,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -897,17 +897,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -925,17 +925,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -950,17 +950,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -978,17 +978,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1012,17 +1012,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1043,17 +1043,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1152,17 +1152,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1186,14 +1186,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1208,14 +1208,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1280,14 +1280,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1302,14 +1302,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1440,14 +1440,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1462,14 +1462,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1593,17 +1593,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1621,17 +1621,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1652,7 +1652,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif index e22dcf742..cc6769838 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -835,14 +835,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -860,17 +860,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -891,17 +891,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -919,17 +919,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -950,17 +950,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -975,17 +975,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1000,17 +1000,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1028,17 +1028,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1062,14 +1062,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1084,14 +1084,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1106,14 +1106,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1131,14 +1131,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1156,14 +1156,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1178,14 +1178,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1222,14 +1222,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1244,14 +1244,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1266,14 +1266,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1288,14 +1288,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1316,14 +1316,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1338,14 +1338,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1360,14 +1360,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1382,17 +1382,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1410,17 +1410,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1438,17 +1438,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1469,17 +1469,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1494,17 +1494,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1528,17 +1528,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1559,17 +1559,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1584,17 +1584,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1612,17 +1612,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif index d0f304d5f..5c4a79b7c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif index 300460d03..274a34a71 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -839,17 +839,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -870,17 +870,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -898,17 +898,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1016,17 +1016,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1041,17 +1041,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1106,14 +1106,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1128,14 +1128,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1150,14 +1150,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1175,14 +1175,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1222,14 +1222,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1244,14 +1244,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1266,14 +1266,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1288,14 +1288,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1310,14 +1310,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1360,14 +1360,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1382,14 +1382,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1404,14 +1404,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1460,17 +1460,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1566,17 +1566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1597,7 +1597,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif index 376d42a07..673767ac9 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif @@ -771,10 +771,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -789,17 +789,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -814,17 +814,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -842,17 +842,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -873,17 +873,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -901,17 +901,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -954,17 +954,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -988,17 +988,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1019,17 +1019,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1044,17 +1044,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1075,17 +1075,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1162,14 +1162,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1184,14 +1184,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1206,14 +1206,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1231,14 +1231,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1256,14 +1256,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1278,14 +1278,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1300,14 +1300,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1322,14 +1322,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1344,14 +1344,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1366,14 +1366,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1388,14 +1388,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1438,14 +1438,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1460,14 +1460,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1516,17 +1516,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1541,17 +1541,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1569,17 +1569,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif index b44604fdf..69a2876c7 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif @@ -785,10 +785,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -803,17 +803,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -828,17 +828,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -856,17 +856,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -887,17 +887,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -915,17 +915,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -940,17 +940,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -968,17 +968,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1002,17 +1002,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1033,17 +1033,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1058,17 +1058,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1092,14 +1092,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1114,14 +1114,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1136,14 +1136,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1161,14 +1161,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1186,14 +1186,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1208,14 +1208,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1252,14 +1252,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1274,14 +1274,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1318,14 +1318,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1418,14 +1418,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1443,17 +1443,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1474,17 +1474,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1505,17 +1505,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1530,17 +1530,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1558,17 +1558,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1583,17 +1583,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1611,17 +1611,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1642,7 +1642,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif index 9e46dd05b..0818bb7dd 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -859,17 +859,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -890,17 +890,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -918,17 +918,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -943,17 +943,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -971,17 +971,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1092,17 +1092,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1126,14 +1126,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1148,14 +1148,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1170,14 +1170,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1195,14 +1195,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1220,14 +1220,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1242,14 +1242,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1264,14 +1264,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1286,14 +1286,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1308,14 +1308,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1330,14 +1330,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1352,14 +1352,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1380,14 +1380,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1402,14 +1402,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1424,14 +1424,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1452,14 +1452,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1477,17 +1477,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif index 3a5b828e6..690b47c23 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -833,17 +833,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -861,17 +861,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -920,17 +920,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -945,17 +945,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -973,17 +973,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1063,17 +1063,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1088,17 +1088,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1116,17 +1116,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1150,14 +1150,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1172,14 +1172,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1194,14 +1194,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1219,14 +1219,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1244,14 +1244,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1266,14 +1266,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1288,14 +1288,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1310,14 +1310,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1354,14 +1354,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1376,14 +1376,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1404,14 +1404,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1426,14 +1426,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1448,14 +1448,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1476,14 +1476,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1501,17 +1501,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1532,17 +1532,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1563,17 +1563,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1588,17 +1588,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1616,17 +1616,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif index 8542a50c3..47c317e3c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif index 0c6ea83fa..b87dd3525 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif index 41f311b97..15c59dd2e 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -839,17 +839,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -870,17 +870,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -898,17 +898,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1016,17 +1016,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1041,17 +1041,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1106,14 +1106,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1128,14 +1128,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1150,14 +1150,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1175,14 +1175,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1222,14 +1222,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1244,14 +1244,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1266,14 +1266,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1288,14 +1288,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1310,14 +1310,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1360,14 +1360,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1382,14 +1382,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1404,14 +1404,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1460,17 +1460,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1566,17 +1566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1597,7 +1597,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif index d8dc2e5b8..ae3afb5ef 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif index baace4b16..de277acf1 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif index 0520c9879..fe6710252 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif index d2d9e2629..6ff6e9931 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif index ae52f39d6..a1582511c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -839,17 +839,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -870,17 +870,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -898,17 +898,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1016,17 +1016,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1041,17 +1041,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1106,14 +1106,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1128,14 +1128,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1150,14 +1150,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1175,14 +1175,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1222,14 +1222,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1244,14 +1244,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1266,14 +1266,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1288,14 +1288,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1310,14 +1310,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1360,14 +1360,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1382,14 +1382,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1404,14 +1404,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1460,17 +1460,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1566,17 +1566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1597,7 +1597,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif index 6e6aafd03..4b0eb009a 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif index f803bb07c..2fac5d68c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -921,17 +921,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -946,17 +946,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1064,17 +1064,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1173,14 +1173,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1198,14 +1198,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1223,14 +1223,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1245,14 +1245,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1267,14 +1267,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1289,14 +1289,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1311,14 +1311,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1333,14 +1333,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1355,14 +1355,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1405,14 +1405,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1427,14 +1427,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1564,17 +1564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1589,17 +1589,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1617,17 +1617,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif index 8118c6ca6..a5195e736 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -859,17 +859,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -890,17 +890,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -918,17 +918,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -943,17 +943,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -971,17 +971,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1092,17 +1092,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1126,14 +1126,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1148,14 +1148,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1170,14 +1170,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1195,14 +1195,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1220,14 +1220,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1242,14 +1242,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1264,14 +1264,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1286,14 +1286,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1308,14 +1308,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1330,14 +1330,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1352,14 +1352,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1380,14 +1380,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1402,14 +1402,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1424,14 +1424,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1452,14 +1452,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1477,17 +1477,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif index 98061a657..cc0d69670 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -859,17 +859,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -890,17 +890,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -918,17 +918,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -943,17 +943,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -971,17 +971,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1092,17 +1092,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1126,14 +1126,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1148,14 +1148,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1170,14 +1170,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1195,14 +1195,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1220,14 +1220,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1242,14 +1242,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1264,14 +1264,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1286,14 +1286,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1308,14 +1308,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1330,14 +1330,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1352,14 +1352,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1380,14 +1380,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1402,14 +1402,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1424,14 +1424,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1452,14 +1452,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1477,17 +1477,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif index 95a41397e..cf2b37287 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif @@ -789,10 +789,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -810,17 +810,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -841,17 +841,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -894,17 +894,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -922,14 +922,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -947,14 +947,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -969,14 +969,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -991,14 +991,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1013,14 +1013,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1035,14 +1035,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1057,14 +1057,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1079,14 +1079,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1107,14 +1107,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1129,14 +1129,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1151,14 +1151,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1173,17 +1173,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1198,17 +1198,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1229,14 +1229,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1254,17 +1254,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1282,17 +1282,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1313,17 +1313,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1344,17 +1344,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1369,17 +1369,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1397,17 +1397,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1431,17 +1431,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1462,17 +1462,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1487,17 +1487,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1512,17 +1512,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1540,17 +1540,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1602,14 +1602,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1624,14 +1624,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1646,7 +1646,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif index 84d8f59c3..cf4cfc795 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif @@ -548,10 +548,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -569,17 +569,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -594,17 +594,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -622,17 +622,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -650,14 +650,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -675,14 +675,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -697,14 +697,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -719,14 +719,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -741,14 +741,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -763,14 +763,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -785,14 +785,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -807,14 +807,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -835,14 +835,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -857,14 +857,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -879,14 +879,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -901,17 +901,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -929,17 +929,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -960,17 +960,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1019,17 +1019,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1075,17 +1075,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1134,7 +1134,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif index c7a7030bc..d63fa0842 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif @@ -787,10 +787,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -808,17 +808,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -833,17 +833,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -861,17 +861,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -889,14 +889,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -914,14 +914,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -936,14 +936,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -958,14 +958,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -980,14 +980,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1002,14 +1002,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1024,14 +1024,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1046,14 +1046,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1074,14 +1074,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1096,14 +1096,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1118,14 +1118,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1140,17 +1140,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1165,17 +1165,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1196,14 +1196,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1221,17 +1221,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1249,17 +1249,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1280,17 +1280,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1311,17 +1311,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1336,17 +1336,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1364,17 +1364,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1398,17 +1398,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1454,17 +1454,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1510,17 +1510,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1569,14 +1569,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1600,14 +1600,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1622,14 +1622,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1644,7 +1644,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif index 13441c362..d2486c068 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -811,17 +811,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -842,17 +842,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -923,14 +923,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1014,14 +1014,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1036,14 +1036,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1058,14 +1058,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1080,14 +1080,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1108,14 +1108,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1130,14 +1130,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1152,14 +1152,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1174,17 +1174,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1199,17 +1199,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1314,17 +1314,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1345,17 +1345,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1370,17 +1370,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1398,17 +1398,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1432,17 +1432,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1463,17 +1463,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1488,17 +1488,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1541,17 +1541,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1603,14 +1603,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1625,14 +1625,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif index dabf629dd..4f06681df 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -811,17 +811,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -842,17 +842,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -923,14 +923,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1014,14 +1014,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1036,14 +1036,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1058,14 +1058,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1080,14 +1080,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1108,14 +1108,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1130,14 +1130,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1152,14 +1152,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1174,17 +1174,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1199,17 +1199,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1314,17 +1314,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1345,17 +1345,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1370,17 +1370,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1398,17 +1398,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1432,17 +1432,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1463,17 +1463,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1488,17 +1488,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1541,17 +1541,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1603,14 +1603,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1625,14 +1625,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif index 714196152..93c24cec6 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -811,17 +811,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -842,17 +842,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -923,14 +923,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1014,14 +1014,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1036,14 +1036,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1058,14 +1058,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1080,14 +1080,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1108,14 +1108,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1130,14 +1130,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1152,14 +1152,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1174,17 +1174,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1199,17 +1199,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1314,17 +1314,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1345,17 +1345,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1370,17 +1370,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1398,17 +1398,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1432,17 +1432,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1463,17 +1463,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1488,17 +1488,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1541,17 +1541,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1603,14 +1603,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1625,14 +1625,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif index 8e43b9e59..e5bbb33ca 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif @@ -550,10 +550,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -571,17 +571,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -602,17 +602,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -627,17 +627,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -655,17 +655,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -683,14 +683,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -708,14 +708,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -730,14 +730,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -752,14 +752,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -774,14 +774,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -796,14 +796,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -818,14 +818,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -868,14 +868,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -890,14 +890,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -912,14 +912,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -934,17 +934,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -962,17 +962,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -993,17 +993,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1018,17 +1018,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1052,17 +1052,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1077,17 +1077,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1105,17 +1105,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1136,7 +1136,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif index 15b954d5f..7d8cf9a8d 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif @@ -784,10 +784,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -802,17 +802,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -830,17 +830,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -858,14 +858,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -883,14 +883,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -905,14 +905,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -927,14 +927,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -949,14 +949,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -971,14 +971,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -993,14 +993,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1015,14 +1015,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1043,14 +1043,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1065,14 +1065,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1087,14 +1087,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1109,17 +1109,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1140,14 +1140,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1165,17 +1165,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1193,17 +1193,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1224,17 +1224,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1280,17 +1280,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1308,17 +1308,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1342,17 +1342,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1373,17 +1373,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1398,17 +1398,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1454,17 +1454,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1482,17 +1482,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1507,17 +1507,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1535,17 +1535,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1566,14 +1566,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1597,14 +1597,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1619,14 +1619,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1641,7 +1641,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif index fab135633..520a7445f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif @@ -548,10 +548,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -566,17 +566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -594,17 +594,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -625,17 +625,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -653,14 +653,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -678,14 +678,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -700,14 +700,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -722,14 +722,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -744,14 +744,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -766,14 +766,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -788,14 +788,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -810,14 +810,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -838,14 +838,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -907,17 +907,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -938,17 +938,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -963,17 +963,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -997,17 +997,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1022,17 +1022,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1075,17 +1075,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1134,7 +1134,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif index cf6a8bc4d..26cddca3f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif @@ -784,10 +784,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -802,17 +802,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -830,17 +830,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -858,14 +858,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -883,14 +883,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -905,14 +905,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -927,14 +927,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -949,14 +949,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -971,14 +971,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -993,14 +993,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1015,14 +1015,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1043,14 +1043,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1065,14 +1065,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1087,14 +1087,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1109,17 +1109,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1140,14 +1140,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1165,17 +1165,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1193,17 +1193,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1224,17 +1224,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1280,17 +1280,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1308,17 +1308,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1342,17 +1342,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1373,17 +1373,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1398,17 +1398,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1454,17 +1454,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1482,17 +1482,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1507,17 +1507,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1535,17 +1535,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1566,14 +1566,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1597,14 +1597,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1619,14 +1619,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1641,7 +1641,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif index 19fdf00ea..7ecb64f5e 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif @@ -770,10 +770,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -788,17 +788,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -841,17 +841,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -872,17 +872,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -900,17 +900,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -928,17 +928,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -962,17 +962,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -993,17 +993,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1018,17 +1018,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1049,17 +1049,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1136,14 +1136,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1158,14 +1158,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1180,14 +1180,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1205,14 +1205,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1252,14 +1252,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1274,14 +1274,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1318,14 +1318,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1340,14 +1340,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1362,14 +1362,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1459,17 +1459,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1490,17 +1490,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1515,17 +1515,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1540,17 +1540,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1599,7 +1599,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif index 66059aa34..03b51076d 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -812,17 +812,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -843,17 +843,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -868,17 +868,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -896,17 +896,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -924,14 +924,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -949,14 +949,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -971,14 +971,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -993,14 +993,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1015,14 +1015,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1037,14 +1037,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1059,14 +1059,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1081,14 +1081,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1109,14 +1109,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1131,14 +1131,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1153,14 +1153,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1175,17 +1175,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1200,17 +1200,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1231,14 +1231,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1256,17 +1256,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1284,17 +1284,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1315,17 +1315,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1346,17 +1346,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1371,17 +1371,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1399,17 +1399,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1433,17 +1433,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1464,17 +1464,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1489,17 +1489,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1514,17 +1514,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1542,17 +1542,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1604,14 +1604,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1626,14 +1626,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif index 9032c9d7f..422242fb3 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif @@ -770,10 +770,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -788,17 +788,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -841,17 +841,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -872,17 +872,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -900,17 +900,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -928,17 +928,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -962,17 +962,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -993,17 +993,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1018,17 +1018,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1049,17 +1049,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1136,14 +1136,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1158,14 +1158,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1180,14 +1180,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1205,14 +1205,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1252,14 +1252,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1274,14 +1274,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1318,14 +1318,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1340,14 +1340,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1362,14 +1362,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1459,17 +1459,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1490,17 +1490,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1515,17 +1515,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1540,17 +1540,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1599,7 +1599,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif index d871a6de1..f5d3fb1dc 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -837,17 +837,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -893,14 +893,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -918,14 +918,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -940,14 +940,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -962,14 +962,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -984,14 +984,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1006,14 +1006,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1028,14 +1028,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1050,14 +1050,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1078,14 +1078,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1100,14 +1100,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1122,14 +1122,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1144,17 +1144,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1169,17 +1169,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1225,17 +1225,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1253,17 +1253,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1284,17 +1284,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1312,17 +1312,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1343,17 +1343,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1368,17 +1368,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1396,17 +1396,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1430,17 +1430,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1461,17 +1461,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1486,17 +1486,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1539,17 +1539,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1570,14 +1570,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1601,14 +1601,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1623,14 +1623,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif index a806bccd9..0db78d336 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif @@ -547,10 +547,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -571,17 +571,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -596,17 +596,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -624,17 +624,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -652,14 +652,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -677,14 +677,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -699,14 +699,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -721,14 +721,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -743,14 +743,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -765,14 +765,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -787,14 +787,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -809,14 +809,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -837,14 +837,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -859,14 +859,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -881,14 +881,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -903,17 +903,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -931,17 +931,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -959,17 +959,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -990,17 +990,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1015,17 +1015,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1049,17 +1049,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1133,7 +1133,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif index 054c162aa..1ff5f8e45 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif @@ -787,10 +787,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -836,17 +836,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -892,14 +892,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -917,14 +917,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -939,14 +939,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -961,14 +961,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -983,14 +983,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1005,14 +1005,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1027,14 +1027,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1049,14 +1049,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1077,14 +1077,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1099,14 +1099,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1121,14 +1121,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1143,17 +1143,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1168,17 +1168,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1199,14 +1199,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1224,17 +1224,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1252,17 +1252,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1311,17 +1311,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1342,17 +1342,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1367,17 +1367,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1395,17 +1395,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1460,17 +1460,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1510,17 +1510,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1569,14 +1569,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1600,14 +1600,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1622,14 +1622,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1644,7 +1644,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif index d1c5f94b6..7c5fee551 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -792,17 +792,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -817,17 +817,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -845,17 +845,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -873,14 +873,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -898,14 +898,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -920,14 +920,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -942,14 +942,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -964,14 +964,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -986,14 +986,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1008,14 +1008,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1030,14 +1030,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1058,14 +1058,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1080,14 +1080,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1102,14 +1102,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1149,17 +1149,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1180,14 +1180,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1205,17 +1205,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1233,17 +1233,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1264,17 +1264,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1292,17 +1292,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1323,17 +1323,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1348,17 +1348,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1376,17 +1376,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1410,17 +1410,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1441,17 +1441,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1466,17 +1466,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1491,17 +1491,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1519,17 +1519,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1603,14 +1603,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1625,7 +1625,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif index 6e7945105..1999bdc38 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif @@ -787,10 +787,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -836,17 +836,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -892,14 +892,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -917,14 +917,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -939,14 +939,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -961,14 +961,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -983,14 +983,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1005,14 +1005,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1027,14 +1027,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1049,14 +1049,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1077,14 +1077,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1099,14 +1099,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1121,14 +1121,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1143,17 +1143,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1168,17 +1168,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1199,14 +1199,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1224,17 +1224,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1252,17 +1252,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1311,17 +1311,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1342,17 +1342,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1367,17 +1367,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1395,17 +1395,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1429,17 +1429,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1460,17 +1460,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1485,17 +1485,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1510,17 +1510,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1569,14 +1569,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1600,14 +1600,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1622,14 +1622,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1644,7 +1644,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif index 8a4f25a9b..adb8fbd53 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif @@ -547,10 +547,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -571,17 +571,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -596,17 +596,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -624,17 +624,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -652,14 +652,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -677,14 +677,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -699,14 +699,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -721,14 +721,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -743,14 +743,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -765,14 +765,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -787,14 +787,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -809,14 +809,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -837,14 +837,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -859,14 +859,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -881,14 +881,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -903,17 +903,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -931,17 +931,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -959,17 +959,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -990,17 +990,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1015,17 +1015,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1049,17 +1049,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1133,7 +1133,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif index 30520d43a..390df395f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -832,17 +832,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -885,14 +885,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -907,14 +907,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -929,14 +929,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -951,14 +951,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -973,14 +973,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -995,14 +995,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1017,14 +1017,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1045,14 +1045,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1067,14 +1067,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1089,14 +1089,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1111,17 +1111,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1136,17 +1136,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1167,14 +1167,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1192,17 +1192,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1220,17 +1220,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1251,17 +1251,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1279,17 +1279,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1310,17 +1310,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1335,17 +1335,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1363,17 +1363,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1397,17 +1397,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1428,17 +1428,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1453,17 +1453,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1484,17 +1484,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1509,17 +1509,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1568,14 +1568,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1599,14 +1599,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1621,14 +1621,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif index 9935e605a..6cceaf06d 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif @@ -761,10 +761,10 @@ "rules": [ { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -779,17 +779,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -807,17 +807,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -835,14 +835,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -904,14 +904,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -926,14 +926,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1020,14 +1020,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1042,14 +1042,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1064,14 +1064,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1086,17 +1086,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1111,17 +1111,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1142,14 +1142,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1167,17 +1167,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1195,17 +1195,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1226,17 +1226,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1254,17 +1254,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1285,17 +1285,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1310,17 +1310,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1338,17 +1338,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1372,17 +1372,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1403,17 +1403,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1428,17 +1428,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1459,17 +1459,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1484,17 +1484,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1512,17 +1512,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1543,14 +1543,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1574,14 +1574,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1596,14 +1596,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1618,7 +1618,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif index 95879d033..2902eda12 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif @@ -783,10 +783,10 @@ "rules": [ { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -801,17 +801,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -829,17 +829,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -857,14 +857,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -904,14 +904,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -926,14 +926,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1014,14 +1014,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1042,14 +1042,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1064,14 +1064,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1086,14 +1086,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1108,17 +1108,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1133,17 +1133,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1164,14 +1164,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1189,17 +1189,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1217,17 +1217,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1248,17 +1248,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1276,17 +1276,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1307,17 +1307,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1332,17 +1332,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1360,17 +1360,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1394,17 +1394,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1425,17 +1425,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1450,17 +1450,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1481,17 +1481,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1506,17 +1506,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1534,17 +1534,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1565,14 +1565,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1596,14 +1596,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1618,14 +1618,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1640,7 +1640,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif index ccb761236..1bec1e465 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif @@ -783,10 +783,10 @@ "rules": [ { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -801,17 +801,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -829,17 +829,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -857,14 +857,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -904,14 +904,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -926,14 +926,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1014,14 +1014,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1042,14 +1042,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1064,14 +1064,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1086,14 +1086,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1108,17 +1108,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1133,17 +1133,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1164,14 +1164,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1189,17 +1189,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1217,17 +1217,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1248,17 +1248,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1276,17 +1276,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1307,17 +1307,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1332,17 +1332,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1360,17 +1360,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1394,17 +1394,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1425,17 +1425,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1450,17 +1450,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1481,17 +1481,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1506,17 +1506,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1534,17 +1534,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1565,14 +1565,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1596,14 +1596,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1618,14 +1618,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1640,7 +1640,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif index 66eed0aa6..104cf2083 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif @@ -789,10 +789,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -807,17 +807,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -835,17 +835,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -894,14 +894,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -919,14 +919,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -941,14 +941,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -963,14 +963,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -985,14 +985,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1007,14 +1007,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1029,14 +1029,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1051,14 +1051,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1079,14 +1079,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1101,14 +1101,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1123,14 +1123,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1145,17 +1145,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1176,14 +1176,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1201,17 +1201,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1229,17 +1229,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1260,17 +1260,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1291,17 +1291,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1316,17 +1316,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1344,17 +1344,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1378,17 +1378,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1409,17 +1409,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1434,17 +1434,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1459,17 +1459,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1487,17 +1487,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1512,17 +1512,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1540,17 +1540,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1602,14 +1602,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1624,14 +1624,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1646,7 +1646,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif index 42bb4375c..9a8dd65a2 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif @@ -789,10 +789,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -807,17 +807,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -835,17 +835,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -894,14 +894,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -919,14 +919,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -941,14 +941,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -963,14 +963,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -985,14 +985,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1007,14 +1007,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1029,14 +1029,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1051,14 +1051,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1079,14 +1079,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1101,14 +1101,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1123,14 +1123,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1145,17 +1145,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1176,14 +1176,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1201,17 +1201,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1229,17 +1229,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1260,17 +1260,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1291,17 +1291,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1316,17 +1316,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1344,17 +1344,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1378,17 +1378,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1409,17 +1409,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1434,17 +1434,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1459,17 +1459,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1487,17 +1487,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1512,17 +1512,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1540,17 +1540,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1602,14 +1602,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1624,14 +1624,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1646,7 +1646,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif index 929259100..ab4e619ba 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif @@ -548,10 +548,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -566,17 +566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -594,17 +594,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -625,17 +625,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -653,14 +653,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -678,14 +678,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -700,14 +700,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -722,14 +722,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -744,14 +744,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -766,14 +766,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -788,14 +788,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -810,14 +810,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -838,14 +838,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -907,17 +907,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -938,17 +938,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -963,17 +963,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -997,17 +997,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1022,17 +1022,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1075,17 +1075,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1134,7 +1134,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif index b29612c1f..947c413bb 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif @@ -793,10 +793,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -836,17 +836,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -923,17 +923,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -951,17 +951,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1016,17 +1016,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1041,17 +1041,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1097,17 +1097,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1159,14 +1159,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1181,14 +1181,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1203,14 +1203,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1228,14 +1228,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1253,14 +1253,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1275,14 +1275,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1297,14 +1297,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1319,14 +1319,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1341,14 +1341,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1363,14 +1363,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1385,14 +1385,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1485,14 +1485,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1510,17 +1510,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1541,17 +1541,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1566,17 +1566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1591,17 +1591,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1619,17 +1619,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1650,7 +1650,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif index 29983f715..99ac8b463 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif @@ -785,10 +785,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -803,17 +803,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -862,14 +862,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -887,14 +887,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -909,14 +909,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -931,14 +931,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -953,14 +953,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -975,14 +975,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -997,14 +997,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1019,14 +1019,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1047,14 +1047,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1069,14 +1069,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1091,14 +1091,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1113,17 +1113,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1144,14 +1144,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1169,17 +1169,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1197,17 +1197,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1228,17 +1228,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1256,17 +1256,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1287,17 +1287,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1312,17 +1312,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1340,17 +1340,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1374,17 +1374,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1405,17 +1405,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1430,17 +1430,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1455,17 +1455,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1483,17 +1483,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1567,14 +1567,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1598,14 +1598,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1620,14 +1620,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1642,7 +1642,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif index 13aff9024..5ceb4ca70 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif @@ -770,10 +770,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -788,17 +788,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -813,17 +813,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -841,17 +841,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -872,17 +872,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -900,17 +900,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -928,17 +928,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -962,17 +962,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -993,17 +993,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1018,17 +1018,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1049,17 +1049,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1136,14 +1136,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1158,14 +1158,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1180,14 +1180,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1205,14 +1205,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1230,14 +1230,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1252,14 +1252,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1274,14 +1274,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1318,14 +1318,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1340,14 +1340,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1362,14 +1362,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1459,17 +1459,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1490,17 +1490,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1515,17 +1515,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1540,17 +1540,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1568,17 +1568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1599,7 +1599,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif index f4d840892..e44a18a4f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -835,17 +835,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -863,14 +863,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -888,14 +888,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -910,14 +910,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -932,14 +932,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -954,14 +954,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -976,14 +976,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -998,14 +998,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1020,14 +1020,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1048,14 +1048,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1070,14 +1070,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1092,14 +1092,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1114,17 +1114,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1145,14 +1145,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1170,17 +1170,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1198,17 +1198,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1229,17 +1229,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1257,17 +1257,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1288,17 +1288,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1313,17 +1313,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1341,17 +1341,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1375,17 +1375,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1406,17 +1406,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1431,17 +1431,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1456,17 +1456,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1484,17 +1484,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1509,17 +1509,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1568,14 +1568,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1599,14 +1599,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1621,14 +1621,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif index ad6747277..5d6f82f31 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -835,17 +835,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -863,14 +863,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -888,14 +888,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -910,14 +910,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -932,14 +932,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -954,14 +954,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -976,14 +976,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -998,14 +998,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1020,14 +1020,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1048,14 +1048,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1070,14 +1070,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1092,14 +1092,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1114,17 +1114,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1145,14 +1145,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1170,17 +1170,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1198,17 +1198,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1229,17 +1229,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1257,17 +1257,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1288,17 +1288,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1313,17 +1313,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1341,17 +1341,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1375,17 +1375,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1406,17 +1406,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1431,17 +1431,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1456,17 +1456,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1484,17 +1484,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1509,17 +1509,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1537,17 +1537,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1568,14 +1568,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1599,14 +1599,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1621,14 +1621,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif index 7f9ace01e..334e7b466 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif @@ -546,10 +546,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -564,17 +564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -595,17 +595,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -623,14 +623,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -648,14 +648,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -670,14 +670,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -692,14 +692,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -714,14 +714,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -736,14 +736,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -758,14 +758,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -780,14 +780,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -808,14 +808,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -830,14 +830,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -852,14 +852,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -877,17 +877,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -905,17 +905,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -936,17 +936,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -961,17 +961,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -995,17 +995,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1020,17 +1020,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1048,17 +1048,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1132,7 +1132,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif index 815688fa4..ef17b9c80 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif @@ -785,10 +785,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -803,17 +803,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -862,14 +862,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -887,14 +887,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -909,14 +909,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -931,14 +931,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -953,14 +953,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -975,14 +975,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -997,14 +997,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1019,14 +1019,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1047,14 +1047,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1069,14 +1069,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1091,14 +1091,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1113,17 +1113,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1144,14 +1144,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1169,17 +1169,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1197,17 +1197,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1228,17 +1228,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1256,17 +1256,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1287,17 +1287,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1312,17 +1312,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1340,17 +1340,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1374,17 +1374,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1405,17 +1405,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1430,17 +1430,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1455,17 +1455,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1483,17 +1483,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1567,14 +1567,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1598,14 +1598,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1620,14 +1620,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1642,7 +1642,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif index 4feb22244..d99b4e6d7 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif @@ -796,10 +796,10 @@ "rules": [ { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -820,17 +820,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -845,17 +845,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -873,17 +873,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -907,14 +907,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -929,14 +929,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -951,14 +951,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -976,14 +976,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1001,14 +1001,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1023,14 +1023,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1045,14 +1045,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1067,14 +1067,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1089,14 +1089,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1111,14 +1111,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1133,14 +1133,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1161,14 +1161,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1183,14 +1183,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1205,14 +1205,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1227,17 +1227,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1252,17 +1252,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1283,14 +1283,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1308,17 +1308,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1336,17 +1336,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1367,17 +1367,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1395,17 +1395,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1426,17 +1426,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1451,17 +1451,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1479,17 +1479,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1513,17 +1513,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1544,17 +1544,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1569,17 +1569,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1594,17 +1594,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1622,17 +1622,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1653,7 +1653,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif index a5b456f82..421b7de43 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif @@ -624,10 +624,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -642,17 +642,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -670,17 +670,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -698,17 +698,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -732,17 +732,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -763,17 +763,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -788,17 +788,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -819,17 +819,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -847,17 +847,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -875,14 +875,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -900,14 +900,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -922,14 +922,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -944,14 +944,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -966,14 +966,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -988,14 +988,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1010,14 +1010,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1032,14 +1032,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1060,14 +1060,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1082,14 +1082,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1104,14 +1104,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1160,17 +1160,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,7 +1294,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif index d356d8b5b..7c15ba8af 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif @@ -550,10 +550,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -568,17 +568,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -596,17 +596,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -627,17 +627,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -655,17 +655,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -683,14 +683,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -708,14 +708,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -730,14 +730,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -752,14 +752,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -774,14 +774,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -796,14 +796,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -818,14 +818,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -868,14 +868,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -890,14 +890,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -912,14 +912,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -937,17 +937,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -968,17 +968,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -993,17 +993,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1027,17 +1027,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1052,17 +1052,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1077,17 +1077,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1105,17 +1105,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1136,7 +1136,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif index 317a07eaa..8b01848ab 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -833,17 +833,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -861,17 +861,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -920,17 +920,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -945,17 +945,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -973,17 +973,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1063,17 +1063,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1094,17 +1094,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1122,17 +1122,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1156,14 +1156,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1178,14 +1178,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1200,14 +1200,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1225,14 +1225,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1250,14 +1250,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1272,14 +1272,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1316,14 +1316,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1338,14 +1338,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1360,14 +1360,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1382,14 +1382,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1410,14 +1410,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1432,14 +1432,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1454,14 +1454,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1507,17 +1507,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1538,17 +1538,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1563,17 +1563,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1588,17 +1588,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1616,17 +1616,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif index b2a40a893..aba82f380 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -859,17 +859,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -890,17 +890,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -918,17 +918,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -943,17 +943,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -971,17 +971,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1092,17 +1092,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1126,14 +1126,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1148,14 +1148,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1170,14 +1170,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1195,14 +1195,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1220,14 +1220,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1242,14 +1242,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1264,14 +1264,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1286,14 +1286,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1308,14 +1308,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1330,14 +1330,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1352,14 +1352,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1380,14 +1380,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1402,14 +1402,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1424,14 +1424,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1452,14 +1452,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1477,17 +1477,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif index dc600b2a0..92bedb105 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif @@ -624,10 +624,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -645,17 +645,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -673,17 +673,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -707,17 +707,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -738,17 +738,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -763,17 +763,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -794,17 +794,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -819,17 +819,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -847,17 +847,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -875,14 +875,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -900,14 +900,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -922,14 +922,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -944,14 +944,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -966,14 +966,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -988,14 +988,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1010,14 +1010,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1032,14 +1032,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1060,14 +1060,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1082,14 +1082,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1104,14 +1104,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1154,17 +1154,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,7 +1294,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif index a204b13bc..f294e1aa7 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif @@ -548,10 +548,10 @@ "rules": [ { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -569,17 +569,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -594,17 +594,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -622,17 +622,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -650,14 +650,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -675,14 +675,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -697,14 +697,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -719,14 +719,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -741,14 +741,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -763,14 +763,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -785,14 +785,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -807,14 +807,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -835,14 +835,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -857,14 +857,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -879,14 +879,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -901,17 +901,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -929,17 +929,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -960,17 +960,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1019,17 +1019,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1075,17 +1075,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1134,7 +1134,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif index 0278ded2f..e73917286 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif @@ -794,10 +794,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -843,17 +843,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -877,14 +877,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -899,14 +899,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -921,14 +921,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -946,14 +946,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -971,14 +971,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -993,14 +993,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1015,14 +1015,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1037,14 +1037,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1059,14 +1059,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1081,14 +1081,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1103,14 +1103,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1131,14 +1131,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1153,14 +1153,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1175,14 +1175,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1197,17 +1197,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1228,14 +1228,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1253,17 +1253,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1281,17 +1281,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1312,17 +1312,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1340,17 +1340,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1371,17 +1371,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1396,17 +1396,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1424,17 +1424,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1458,17 +1458,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1489,17 +1489,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1514,17 +1514,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1539,17 +1539,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1567,17 +1567,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1592,17 +1592,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1620,17 +1620,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1651,7 +1651,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif index 50a1ecc3e..1376f9927 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif @@ -794,10 +794,10 @@ "rules": [ { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -840,17 +840,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -874,14 +874,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -896,14 +896,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -918,14 +918,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -943,14 +943,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -968,14 +968,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -990,14 +990,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1012,14 +1012,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1034,14 +1034,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1056,14 +1056,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1078,14 +1078,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1100,14 +1100,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1128,14 +1128,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1150,14 +1150,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1172,14 +1172,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1194,17 +1194,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1219,17 +1219,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1250,14 +1250,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1275,17 +1275,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1303,17 +1303,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1334,17 +1334,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1362,17 +1362,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1393,17 +1393,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1418,17 +1418,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1446,17 +1446,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1480,17 +1480,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1511,17 +1511,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1536,17 +1536,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1567,17 +1567,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1592,17 +1592,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1620,17 +1620,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1651,7 +1651,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif index b8fbf1d45..bb41fdf1a 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif @@ -622,10 +622,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -640,17 +640,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -668,17 +668,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -696,17 +696,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -730,17 +730,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -761,17 +761,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -817,17 +817,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -845,14 +845,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -870,14 +870,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -892,14 +892,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -914,14 +914,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -936,14 +936,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -958,14 +958,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -980,14 +980,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1002,14 +1002,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1030,14 +1030,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1052,14 +1052,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1074,14 +1074,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1130,17 +1130,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1155,17 +1155,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1180,17 +1180,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1208,17 +1208,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1233,17 +1233,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1261,17 +1261,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1292,7 +1292,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif index 48497a80d..cf19c56eb 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif @@ -548,10 +548,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -566,17 +566,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -594,17 +594,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -625,17 +625,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -653,14 +653,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -678,14 +678,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -700,14 +700,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -722,14 +722,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -744,14 +744,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -766,14 +766,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -788,14 +788,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -810,14 +810,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -838,14 +838,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -907,17 +907,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -938,17 +938,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -963,17 +963,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -997,17 +997,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1022,17 +1022,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1075,17 +1075,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1134,7 +1134,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif index fa8670fd6..aae2ead9f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif @@ -794,10 +794,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -843,17 +843,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -877,14 +877,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -899,14 +899,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -921,14 +921,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -946,14 +946,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -971,14 +971,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -993,14 +993,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1015,14 +1015,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1037,14 +1037,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1059,14 +1059,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1081,14 +1081,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1103,14 +1103,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1131,14 +1131,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1153,14 +1153,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1175,14 +1175,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1197,17 +1197,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1228,14 +1228,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1253,17 +1253,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1281,17 +1281,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1312,17 +1312,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1340,17 +1340,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1371,17 +1371,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1396,17 +1396,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1424,17 +1424,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1458,17 +1458,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1489,17 +1489,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1514,17 +1514,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1539,17 +1539,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1567,17 +1567,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1592,17 +1592,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1620,17 +1620,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1651,7 +1651,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif index 38aaad5c5..7619fcd9c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif @@ -788,10 +788,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -831,17 +831,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -862,14 +862,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -887,17 +887,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -918,17 +918,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -946,17 +946,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -974,17 +974,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1030,17 +1030,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1095,14 +1095,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1117,14 +1117,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1139,14 +1139,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1164,14 +1164,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1189,14 +1189,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1211,14 +1211,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1233,14 +1233,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1255,14 +1255,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1277,14 +1277,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1299,14 +1299,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1321,14 +1321,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1418,17 +1418,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1449,17 +1449,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1474,17 +1474,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1508,17 +1508,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1533,17 +1533,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1561,17 +1561,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1586,17 +1586,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1614,17 +1614,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1645,7 +1645,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif index bbdc49129..270f9426b 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif index 7b2f7e84b..72b34d1f1 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif @@ -790,10 +790,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -833,17 +833,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -864,14 +864,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -889,17 +889,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -917,17 +917,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -948,17 +948,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -976,17 +976,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1032,17 +1032,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1060,17 +1060,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1094,17 +1094,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1150,17 +1150,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1206,17 +1206,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1259,17 +1259,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1287,17 +1287,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1318,14 +1318,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1437,14 +1437,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1509,14 +1509,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1534,14 +1534,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1603,14 +1603,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1625,14 +1625,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1647,7 +1647,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif index 0e544ef02..e802a321c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1441,14 +1441,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1463,14 +1463,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1485,14 +1485,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1510,14 +1510,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1535,14 +1535,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1557,14 +1557,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1579,14 +1579,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif index 006f5ebd4..bdbff877c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif @@ -767,10 +767,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -785,17 +785,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -810,17 +810,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -841,14 +841,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -894,17 +894,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -925,17 +925,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -953,17 +953,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -984,17 +984,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1009,17 +1009,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1037,17 +1037,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1071,17 +1071,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1127,17 +1127,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1158,17 +1158,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1183,17 +1183,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1211,17 +1211,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1236,17 +1236,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1264,17 +1264,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1295,14 +1295,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1326,14 +1326,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1348,14 +1348,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1370,14 +1370,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1392,14 +1392,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1414,14 +1414,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1442,14 +1442,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1464,14 +1464,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1486,14 +1486,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1511,14 +1511,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1536,14 +1536,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1558,14 +1558,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1580,14 +1580,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1602,7 +1602,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif index 2f71a5cf8..41532e566 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif @@ -769,10 +769,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -787,17 +787,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -843,14 +843,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -868,17 +868,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -896,17 +896,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -955,17 +955,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -986,17 +986,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1011,17 +1011,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1104,17 +1104,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1160,17 +1160,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1213,17 +1213,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1238,17 +1238,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1266,17 +1266,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1297,14 +1297,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1328,14 +1328,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1350,14 +1350,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1372,14 +1372,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1394,14 +1394,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1444,14 +1444,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1466,14 +1466,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1488,14 +1488,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1513,14 +1513,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1538,14 +1538,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1560,14 +1560,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1582,14 +1582,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1604,7 +1604,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif index 43b92a5a0..e521a60f5 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif index ed0c44d0c..3414d217e 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif index e43b55a5d..82fd8d57d 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif index 46fb26cc1..b5566a7e6 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif @@ -769,10 +769,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -787,17 +787,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -843,14 +843,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -868,17 +868,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -896,17 +896,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -955,17 +955,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -986,17 +986,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1011,17 +1011,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1104,17 +1104,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1160,17 +1160,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1213,17 +1213,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1238,17 +1238,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1266,17 +1266,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1297,14 +1297,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1328,14 +1328,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1350,14 +1350,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1372,14 +1372,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1394,14 +1394,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1444,14 +1444,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1466,14 +1466,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1488,14 +1488,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1513,14 +1513,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1538,14 +1538,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1560,14 +1560,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1582,14 +1582,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1604,7 +1604,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif index 02ef550bd..04021c48a 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif index 0a41131de..96980abd5 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif @@ -780,10 +780,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -798,17 +798,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -823,17 +823,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -854,14 +854,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -879,17 +879,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -907,17 +907,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -938,17 +938,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -966,17 +966,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -997,17 +997,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1022,17 +1022,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1084,17 +1084,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1115,17 +1115,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1140,17 +1140,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1171,17 +1171,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1196,17 +1196,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1224,17 +1224,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1249,17 +1249,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1277,17 +1277,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1308,14 +1308,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1339,14 +1339,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1361,14 +1361,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1408,14 +1408,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1477,14 +1477,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1499,14 +1499,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1521,14 +1521,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1543,14 +1543,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1593,14 +1593,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1615,7 +1615,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif index 0b2801743..fd0d9e885 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif @@ -769,10 +769,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -787,17 +787,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -843,14 +843,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -868,17 +868,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -896,17 +896,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -955,17 +955,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -986,17 +986,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1011,17 +1011,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1104,17 +1104,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1160,17 +1160,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1213,17 +1213,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1238,17 +1238,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1266,17 +1266,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1297,14 +1297,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1328,14 +1328,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1350,14 +1350,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1372,14 +1372,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1394,14 +1394,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1444,14 +1444,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1466,14 +1466,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1488,14 +1488,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1513,14 +1513,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1538,14 +1538,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1560,14 +1560,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1582,14 +1582,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1604,7 +1604,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif index 68c182933..c11c12693 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif index 7147c90cf..12763bbb6 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif @@ -767,10 +767,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -785,17 +785,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -810,17 +810,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -841,14 +841,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -866,17 +866,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -894,17 +894,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -925,17 +925,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -953,17 +953,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -984,17 +984,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1009,17 +1009,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1037,17 +1037,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1071,17 +1071,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1102,17 +1102,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1127,17 +1127,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1158,17 +1158,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1183,17 +1183,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1211,17 +1211,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1236,17 +1236,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1264,17 +1264,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1295,14 +1295,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1326,14 +1326,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1348,14 +1348,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1370,14 +1370,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1392,14 +1392,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1414,14 +1414,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1442,14 +1442,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1464,14 +1464,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1486,14 +1486,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1511,14 +1511,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1536,14 +1536,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1558,14 +1558,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1580,14 +1580,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1602,7 +1602,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif index c48dcf63a..122292cfd 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif @@ -769,10 +769,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -787,17 +787,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -843,14 +843,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -868,17 +868,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -896,17 +896,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -955,17 +955,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -986,17 +986,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1011,17 +1011,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1104,17 +1104,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1160,17 +1160,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1213,17 +1213,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1238,17 +1238,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1266,17 +1266,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1297,14 +1297,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1328,14 +1328,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1350,14 +1350,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1372,14 +1372,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1394,14 +1394,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1444,14 +1444,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1466,14 +1466,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1488,14 +1488,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1513,14 +1513,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1538,14 +1538,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1560,14 +1560,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1582,14 +1582,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1604,7 +1604,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif index ef272b59e..0a16c0ede 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif @@ -38,18 +38,6 @@ "executionSuccessful": true } ], - "artifacts": [ - { - "location": { - "uri": "file:///Z:/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/clang.stack_protector.a" - }, - "hashes": { - "md5": "2400EE99A6BB7B792A67A03A59385018", - "sha-1": "525CB4CBA8B8F80539BBC86C2D78A4275279D8F6", - "sha-256": "41BF336F8AB7D9A6246D37A6EC7210D4BE07893836890BAB0BFEDA98ACEDE87D" - } - } - ], "columnKind": "utf16CodeUnits" } ] diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif index 4a5305958..e92e60937 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1443,14 +1443,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1465,14 +1465,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1487,14 +1487,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1512,14 +1512,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1537,14 +1537,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1559,14 +1559,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1581,14 +1581,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif index 2dc9dc91b..8b955d0f2 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif @@ -769,10 +769,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -787,17 +787,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -812,17 +812,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -843,14 +843,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -868,17 +868,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -896,17 +896,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -927,17 +927,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -955,17 +955,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -986,17 +986,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1011,17 +1011,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1039,17 +1039,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1104,17 +1104,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1129,17 +1129,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1160,17 +1160,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1185,17 +1185,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1213,17 +1213,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1238,17 +1238,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1266,17 +1266,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1297,14 +1297,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1328,14 +1328,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1350,14 +1350,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1372,14 +1372,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1394,14 +1394,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1444,14 +1444,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1466,14 +1466,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1488,14 +1488,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1513,14 +1513,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1538,14 +1538,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1560,14 +1560,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1582,14 +1582,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1604,7 +1604,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif index de42adec0..5c598c82f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif @@ -783,10 +783,10 @@ "rules": [ { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -801,17 +801,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -829,17 +829,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -857,14 +857,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -882,14 +882,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -904,14 +904,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -926,14 +926,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -948,14 +948,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -970,14 +970,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -992,14 +992,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1014,14 +1014,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1042,14 +1042,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1064,14 +1064,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1086,14 +1086,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -1108,17 +1108,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -1133,17 +1133,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -1164,14 +1164,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -1189,17 +1189,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -1217,17 +1217,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -1248,17 +1248,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -1276,17 +1276,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1307,17 +1307,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1332,17 +1332,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1360,17 +1360,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1394,17 +1394,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1425,17 +1425,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1450,17 +1450,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1481,17 +1481,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1506,17 +1506,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1534,17 +1534,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1565,14 +1565,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1596,14 +1596,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1618,14 +1618,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1640,7 +1640,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif index ce00f81c7..2c412bf63 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif index 21efb5993..9ade577ba 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -829,17 +829,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -885,17 +885,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -913,17 +913,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -944,17 +944,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -972,17 +972,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1003,17 +1003,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1028,17 +1028,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1056,17 +1056,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1090,17 +1090,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1121,17 +1121,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1146,17 +1146,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1177,17 +1177,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1202,17 +1202,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1230,17 +1230,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1314,14 +1314,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1411,14 +1411,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1458,14 +1458,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1483,14 +1483,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1505,14 +1505,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1527,14 +1527,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1549,14 +1549,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1593,14 +1593,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1615,14 +1615,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif index 4505ff73a..9f4544156 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif @@ -763,10 +763,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -781,17 +781,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -806,17 +806,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -837,14 +837,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -862,17 +862,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -890,17 +890,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -921,17 +921,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -949,17 +949,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -980,17 +980,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1005,17 +1005,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1033,17 +1033,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1067,17 +1067,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1098,17 +1098,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1123,17 +1123,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1154,17 +1154,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1179,17 +1179,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1207,17 +1207,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1232,17 +1232,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1260,17 +1260,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1291,14 +1291,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1322,14 +1322,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1344,14 +1344,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1366,14 +1366,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1388,14 +1388,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1410,14 +1410,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1432,14 +1432,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1454,14 +1454,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1479,14 +1479,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1504,14 +1504,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1526,14 +1526,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1548,14 +1548,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1570,14 +1570,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1598,7 +1598,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif index dc34fe47e..3c3a2cbca 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif @@ -764,10 +764,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -782,17 +782,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -807,17 +807,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -838,14 +838,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -863,17 +863,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -891,17 +891,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -922,17 +922,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -950,17 +950,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -981,17 +981,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1006,17 +1006,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1034,17 +1034,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1155,17 +1155,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1180,17 +1180,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1208,17 +1208,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1233,17 +1233,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1261,17 +1261,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1292,14 +1292,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1323,14 +1323,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1411,14 +1411,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1480,14 +1480,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1505,14 +1505,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1527,14 +1527,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1549,14 +1549,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1599,7 +1599,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif index f960deb6c..5cf054d71 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif index 2cde19251..ae56b4c00 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif @@ -804,10 +804,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -822,17 +822,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -847,17 +847,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -878,14 +878,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -903,17 +903,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -931,17 +931,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -962,17 +962,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -990,17 +990,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1021,17 +1021,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1046,17 +1046,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1108,17 +1108,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1139,17 +1139,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1164,17 +1164,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1195,17 +1195,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1220,17 +1220,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1248,17 +1248,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1273,17 +1273,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1301,17 +1301,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1363,14 +1363,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1385,14 +1385,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1407,14 +1407,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1432,14 +1432,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1479,14 +1479,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1501,14 +1501,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1523,14 +1523,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1545,14 +1545,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1567,14 +1567,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1589,14 +1589,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1617,14 +1617,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1639,14 +1639,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1661,7 +1661,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif index 8d9950746..eb81c5f9b 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif @@ -791,10 +791,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -834,17 +834,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -865,14 +865,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -890,17 +890,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -918,17 +918,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -949,17 +949,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -977,17 +977,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1033,17 +1033,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1061,17 +1061,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1095,17 +1095,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1151,17 +1151,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1207,17 +1207,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1260,17 +1260,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1288,17 +1288,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1319,14 +1319,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1350,14 +1350,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1372,14 +1372,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1394,14 +1394,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1416,14 +1416,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1438,14 +1438,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1460,14 +1460,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1532,14 +1532,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1554,14 +1554,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1576,14 +1576,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1598,14 +1598,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1620,14 +1620,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1648,7 +1648,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif index 9ae289069..a55ee2620 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -829,17 +829,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -885,17 +885,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -913,17 +913,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -944,17 +944,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -972,17 +972,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1003,17 +1003,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1028,17 +1028,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1056,17 +1056,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1090,17 +1090,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1121,17 +1121,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1146,17 +1146,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1177,17 +1177,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1202,17 +1202,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1230,17 +1230,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1314,14 +1314,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1411,14 +1411,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1458,14 +1458,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1483,14 +1483,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1505,14 +1505,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1527,14 +1527,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1549,14 +1549,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1593,14 +1593,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1615,14 +1615,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif index 9d57a1972..e0322e288 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif @@ -787,10 +787,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -805,17 +805,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -830,17 +830,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -861,14 +861,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -886,17 +886,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -914,17 +914,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -945,17 +945,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -973,17 +973,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1004,17 +1004,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1029,17 +1029,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1057,17 +1057,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1091,17 +1091,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1122,17 +1122,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1147,17 +1147,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1178,17 +1178,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1203,17 +1203,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1231,17 +1231,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1256,17 +1256,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1284,17 +1284,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1315,14 +1315,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1459,14 +1459,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1594,14 +1594,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1616,14 +1616,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1644,7 +1644,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif index 9fdc9593e..6d69fd7c1 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif @@ -785,10 +785,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -803,17 +803,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -828,17 +828,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -859,14 +859,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -884,17 +884,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -912,17 +912,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -943,17 +943,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -971,17 +971,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1002,17 +1002,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1027,17 +1027,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1055,17 +1055,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1089,17 +1089,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1120,17 +1120,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1145,17 +1145,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1176,17 +1176,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1201,17 +1201,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1229,17 +1229,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1254,17 +1254,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1282,17 +1282,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1313,14 +1313,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1344,14 +1344,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1366,14 +1366,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1388,14 +1388,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1410,14 +1410,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1432,14 +1432,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1504,14 +1504,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1526,14 +1526,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1548,14 +1548,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1570,14 +1570,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1592,14 +1592,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1614,14 +1614,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1642,7 +1642,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif index cf64d599b..d57d4b37a 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif @@ -768,10 +768,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -786,17 +786,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -811,17 +811,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -842,14 +842,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -867,17 +867,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -895,17 +895,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -926,17 +926,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -954,17 +954,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -985,17 +985,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1010,17 +1010,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1038,17 +1038,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1072,17 +1072,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1103,17 +1103,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1128,17 +1128,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1159,17 +1159,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1184,17 +1184,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1212,17 +1212,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1237,17 +1237,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1265,17 +1265,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1296,14 +1296,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1327,14 +1327,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1349,14 +1349,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1371,14 +1371,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1393,14 +1393,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1415,14 +1415,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1437,14 +1437,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1459,14 +1459,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1509,14 +1509,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1531,14 +1531,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1553,14 +1553,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1575,14 +1575,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1603,7 +1603,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif index f5b8ac7a4..70c45bfc2 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif @@ -787,10 +787,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -805,17 +805,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -830,17 +830,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -861,14 +861,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -886,17 +886,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -914,17 +914,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -945,17 +945,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -973,17 +973,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1004,17 +1004,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1029,17 +1029,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1057,17 +1057,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1091,17 +1091,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1122,17 +1122,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1147,17 +1147,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1178,17 +1178,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1203,17 +1203,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1231,17 +1231,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1256,17 +1256,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1284,17 +1284,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1315,14 +1315,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1459,14 +1459,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1594,14 +1594,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1616,14 +1616,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1644,7 +1644,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif index a0c7aa7f8..e3b17ecc1 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif index 35217331f..42d64be78 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif index 4ab87a2ac..3e6675100 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif index 4dcda324a..01d71944f 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif index e6498d366..acc51e4e6 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif index 47a394dca..ff9799bf9 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif index 38e30ada3..72f03defc 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif index dc36e1ebe..72e389db1 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif @@ -804,10 +804,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -822,17 +822,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -847,17 +847,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -878,14 +878,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -903,17 +903,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -931,17 +931,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -962,17 +962,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -990,17 +990,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1021,17 +1021,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1046,17 +1046,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1074,17 +1074,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1108,17 +1108,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1139,17 +1139,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1164,17 +1164,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1195,17 +1195,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1220,17 +1220,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1248,17 +1248,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1273,17 +1273,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1301,17 +1301,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1332,14 +1332,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1363,14 +1363,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1385,14 +1385,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1407,14 +1407,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1432,14 +1432,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1479,14 +1479,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1501,14 +1501,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1523,14 +1523,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1545,14 +1545,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1567,14 +1567,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1589,14 +1589,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1617,14 +1617,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1639,14 +1639,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1661,7 +1661,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif index f5692be5b..b69ee0748 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif @@ -764,10 +764,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -782,17 +782,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -807,17 +807,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -838,14 +838,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -863,17 +863,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -891,17 +891,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -922,17 +922,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -950,17 +950,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -981,17 +981,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1006,17 +1006,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1034,17 +1034,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1155,17 +1155,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1180,17 +1180,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1208,17 +1208,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1233,17 +1233,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1261,17 +1261,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1292,14 +1292,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1323,14 +1323,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1411,14 +1411,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1436,14 +1436,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1461,14 +1461,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1483,14 +1483,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1505,14 +1505,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1527,14 +1527,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1549,14 +1549,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1599,7 +1599,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif index 2b889b4af..e32955879 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif @@ -780,10 +780,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -798,17 +798,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -823,17 +823,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -854,14 +854,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -879,17 +879,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -907,17 +907,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -938,17 +938,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -966,17 +966,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -997,17 +997,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1022,17 +1022,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1050,17 +1050,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1084,17 +1084,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1115,17 +1115,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1140,17 +1140,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1171,17 +1171,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1196,17 +1196,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1224,17 +1224,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1249,17 +1249,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1277,17 +1277,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1308,14 +1308,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1339,14 +1339,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1361,14 +1361,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1383,14 +1383,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1408,14 +1408,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1477,14 +1477,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1499,14 +1499,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1521,14 +1521,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1543,14 +1543,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1593,14 +1593,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1615,7 +1615,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif index de066311b..90901f283 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif @@ -546,10 +546,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -564,17 +564,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -592,17 +592,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -623,17 +623,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -651,14 +651,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -676,14 +676,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -698,14 +698,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -720,14 +720,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -742,14 +742,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -764,14 +764,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -786,14 +786,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -808,14 +808,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -836,14 +836,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -858,14 +858,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -880,14 +880,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -905,17 +905,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -936,17 +936,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -961,17 +961,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -995,17 +995,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1020,17 +1020,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1048,17 +1048,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1073,17 +1073,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1132,7 +1132,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif index 7a31b65dd..afcacda02 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif index 129304a9e..2f1d0f841 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif index 71ffc0b1e..54f79e78a 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif @@ -764,10 +764,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -782,17 +782,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -807,17 +807,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -838,14 +838,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -863,17 +863,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -891,17 +891,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -922,17 +922,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -950,17 +950,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -981,17 +981,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1006,17 +1006,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1034,17 +1034,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1068,17 +1068,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1099,17 +1099,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1124,17 +1124,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1155,17 +1155,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1180,17 +1180,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1208,17 +1208,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1233,17 +1233,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1261,17 +1261,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1292,14 +1292,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1323,14 +1323,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1411,14 +1411,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1455,14 +1455,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1480,14 +1480,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1505,14 +1505,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1527,14 +1527,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1549,14 +1549,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1599,7 +1599,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif index 50d43532d..657012d95 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif @@ -786,10 +786,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -804,17 +804,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -829,17 +829,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -860,14 +860,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -885,17 +885,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -913,17 +913,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -944,17 +944,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -972,17 +972,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1003,17 +1003,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1028,17 +1028,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1056,17 +1056,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1090,17 +1090,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1121,17 +1121,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1146,17 +1146,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1177,17 +1177,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1202,17 +1202,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1230,17 +1230,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1255,17 +1255,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1283,17 +1283,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1314,14 +1314,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1345,14 +1345,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1367,14 +1367,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1389,14 +1389,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1411,14 +1411,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1433,14 +1433,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1458,14 +1458,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1483,14 +1483,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1505,14 +1505,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1527,14 +1527,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1549,14 +1549,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1571,14 +1571,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1593,14 +1593,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1615,14 +1615,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1643,7 +1643,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif index 16028c0e8..5a1af857c 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif @@ -787,10 +787,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -805,17 +805,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -830,17 +830,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -861,14 +861,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -886,17 +886,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -914,17 +914,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -945,17 +945,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -973,17 +973,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -1004,17 +1004,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1029,17 +1029,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1057,17 +1057,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1091,17 +1091,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1122,17 +1122,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1147,17 +1147,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1178,17 +1178,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1203,17 +1203,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1231,17 +1231,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1256,17 +1256,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1284,17 +1284,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1315,14 +1315,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1459,14 +1459,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1484,14 +1484,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3004", + "name": "GenerateRequiredSymbolFormat", "fullDescription": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat", "help": { "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "GenerateRequiredSymbolFormat" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1594,14 +1594,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1616,14 +1616,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1644,7 +1644,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif index 988b54661..2e5ab3c2a 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif index 989407353..571e94205 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif @@ -38,18 +38,6 @@ "executionSuccessful": true } ], - "artifacts": [ - { - "location": { - "uri": "file:///Z:/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/gcc.stack_protector.a" - }, - "hashes": { - "md5": "764B913022B393EAF22F96014401576F", - "sha-1": "4B49DA507C9212490EE09280A5A7AD1F1A389188", - "sha-256": "8548292CA34C14D090A1DE7327874010E3A7ACE5846B2E28D743CC0F35C069CB" - } - } - ], "columnKind": "utf16CodeUnits" } ] diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif index 03618d784..3aca50f8b 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif index 60341f525..539627071 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif @@ -766,10 +766,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -784,17 +784,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -809,17 +809,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -840,14 +840,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -865,17 +865,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -893,17 +893,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -924,17 +924,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -952,17 +952,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -983,17 +983,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1008,17 +1008,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1036,17 +1036,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1070,17 +1070,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1101,17 +1101,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1126,17 +1126,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1157,17 +1157,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1182,17 +1182,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1210,17 +1210,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1235,17 +1235,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1263,17 +1263,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1294,14 +1294,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1325,14 +1325,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1347,14 +1347,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1369,14 +1369,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1391,14 +1391,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1413,14 +1413,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1435,14 +1435,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1457,14 +1457,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1482,14 +1482,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1507,14 +1507,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1529,14 +1529,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1551,14 +1551,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1573,14 +1573,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1601,7 +1601,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif index abecdfb73..dbefbf623 100644 --- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif +++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif @@ -765,10 +765,10 @@ "rules": [ { "id": "BA2001", + "name": "LoadImageAboveFourGigabyteAddress", "fullDescription": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "help": { "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries." }, @@ -783,17 +783,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "LoadImageAboveFourGigabyteAddress", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress", "properties": { "equivalentBinScopeRuleReadableName": "FourGbCheck" } }, { "id": "BA2002", + "name": "DoNotIncorporateVulnerableDependencies", "fullDescription": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "help": { "text": "Binaries should not take dependencies on code with known security vulnerabilities." }, @@ -808,17 +808,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotIncorporateVulnerableDependencies", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies", "properties": { "equivalentBinScopeRuleReadableName": "ATLVersionCheck" } }, { "id": "BA2004", + "name": "EnableSecureSourceCodeHashing", "fullDescription": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing", "help": { "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing." }, @@ -839,14 +839,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSecureSourceCodeHashing" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing" }, { "id": "BA2005", + "name": "DoNotShipVulnerableBinaries", "fullDescription": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "help": { "text": "Do not ship obsolete libraries for which there are known security vulnerabilities." }, @@ -864,17 +864,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotShipVulnerableBinaries", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries", "properties": { "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck" } }, { "id": "BA2006", + "name": "BuildWithSecureTools", "fullDescription": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "help": { "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks." }, @@ -892,17 +892,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "BuildWithSecureTools", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools", "properties": { "equivalentBinScopeRuleReadableName": "CompilerVersionCheck" } }, { "id": "BA2007", + "name": "EnableCriticalCompilerWarnings", "fullDescription": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "help": { "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted." }, @@ -923,17 +923,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableCriticalCompilerWarnings", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings", "properties": { "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck" } }, { "id": "BA2008", + "name": "EnableControlFlowGuard", "fullDescription": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "help": { "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location. If that check fails at runtime, the operating system will close the program." }, @@ -951,17 +951,17 @@ "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries." } }, - "name": "EnableControlFlowGuard", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard", "properties": { "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck" } }, { "id": "BA2009", + "name": "EnableAddressSpaceLayoutRandomization", "fullDescription": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "help": { "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later." }, @@ -982,17 +982,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAddressSpaceLayoutRandomization", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization", "properties": { "equivalentBinScopeRuleReadableName": "DBCheck" } }, { "id": "BA2010", + "name": "DoNotMarkImportsSectionAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section." }, @@ -1007,17 +1007,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkImportsSectionAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck" } }, { "id": "BA2011", + "name": "EnableStackProtection", "fullDescription": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "help": { "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line." }, @@ -1035,17 +1035,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSCheck" } }, { "id": "BA2012", + "name": "DoNotModifyStackProtectionCookie", "fullDescription": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "help": { "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement." }, @@ -1069,17 +1069,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotModifyStackProtectionCookie", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie", "properties": { "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck" } }, { "id": "BA2013", + "name": "InitializeStackProtection", "fullDescription": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "help": { "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point." }, @@ -1100,17 +1100,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "InitializeStackProtection", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection", "properties": { "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck" } }, { "id": "BA2014", + "name": "DoNotDisableStackProtectionForFunctions", "fullDescription": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "help": { "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether." }, @@ -1125,17 +1125,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotDisableStackProtectionForFunctions", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions", "properties": { "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck" } }, { "id": "BA2015", + "name": "EnableHighEntropyVirtualAddresses", "fullDescription": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "help": { "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR." }, @@ -1156,17 +1156,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableHighEntropyVirtualAddresses", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses", "properties": { "equivalentBinScopeRuleReadableName": "HighEntropyVACheck" } }, { "id": "BA2016", + "name": "MarkImageAsNXCompatible", "fullDescription": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "help": { "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker." }, @@ -1181,17 +1181,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "MarkImageAsNXCompatible", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible", "properties": { "equivalentBinScopeRuleReadableName": "NXCheck" } }, { "id": "BA2018", + "name": "EnableSafeSEH", "fullDescription": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "help": { "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64." }, @@ -1209,17 +1209,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSafeSEH", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH", "properties": { "equivalentBinScopeRuleReadableName": "SafeSEHCheck" } }, { "id": "BA2019", + "name": "DoNotMarkWritableSectionsAsShared", "fullDescription": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "help": { "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)." }, @@ -1234,17 +1234,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsShared", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared", "properties": { "equivalentBinScopeRuleReadableName": "SharedSectionCheck" } }, { "id": "BA2021", + "name": "DoNotMarkWritableSectionsAsExecutable", "fullDescription": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "help": { "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function." }, @@ -1262,17 +1262,17 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkWritableSectionsAsExecutable", + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable", "properties": { "equivalentBinScopeRuleReadableName": "WXCheck" } }, { "id": "BA2022", + "name": "SignSecurely", "fullDescription": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely", "help": { "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds." }, @@ -1293,14 +1293,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "SignSecurely" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely" }, { "id": "BA2024", + "name": "EnableSpectreMitigations", "fullDescription": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations", "help": { "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it." }, @@ -1324,14 +1324,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableSpectreMitigations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations" }, { "id": "BA2025", + "name": "EnableShadowStack", "fullDescription": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack", "help": { "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks." }, @@ -1346,14 +1346,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableShadowStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack" }, { "id": "BA2026", + "name": "EnableAdditionalSdlSecurityChecks", "fullDescription": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks", "help": { "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks." }, @@ -1368,14 +1368,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableAdditionalSdlSecurityChecks" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks" }, { "id": "BA3003", + "name": "EnableStackProtector", "fullDescription": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector", "help": { "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this." }, @@ -1390,14 +1390,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackProtector" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector" }, { "id": "BA3005", + "name": "EnableStackClashProtection", "fullDescription": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection", "help": { "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this." }, @@ -1412,14 +1412,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableStackClashProtection" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection" }, { "id": "BA5001", + "name": "EnablePositionIndependentExecutableMachO", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1434,14 +1434,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutableMachO" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO" }, { "id": "BA5002", + "name": "DoNotAllowExecutableStack", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"." }, @@ -1456,14 +1456,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotAllowExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack" }, { "id": "BA3001", + "name": "EnablePositionIndependentExecutable", "fullDescription": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable", "help": { "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc." }, @@ -1481,14 +1481,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnablePositionIndependentExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable" }, { "id": "BA3002", + "name": "DoNotMarkStackAsExecutable", "fullDescription": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable", "help": { "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable." }, @@ -1506,14 +1506,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "DoNotMarkStackAsExecutable" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable" }, { "id": "BA3006", + "name": "EnableNonExecutableStack", "fullDescription": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack", "help": { "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this." }, @@ -1528,14 +1528,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableNonExecutableStack" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack" }, { "id": "BA3010", + "name": "EnableReadOnlyRelocations", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this." }, @@ -1550,14 +1550,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableReadOnlyRelocations" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations" }, { "id": "BA3011", + "name": "EnableBindNow", "fullDescription": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow", "help": { "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this." }, @@ -1572,14 +1572,14 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "EnableBindNow" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow" }, { "id": "BA3030", + "name": "UseCheckedFunctionsWithGcc", "fullDescription": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, - "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc", "help": { "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')." }, @@ -1600,7 +1600,7 @@ "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}." } }, - "name": "UseCheckedFunctionsWithGcc" + "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc" } ], "properties": { diff --git a/src/sarif-sdk b/src/sarif-sdk index c18abd737..626337932 160000 --- a/src/sarif-sdk +++ b/src/sarif-sdk @@ -1 +1 @@ -Subproject commit c18abd737d34263aa21cb15e9df2be91e1d98208 +Subproject commit 626337932472cb6e197e998687dae35ee14b8c8d